1. Field of the Invention
The present invention relates generally to communication systems and more particularly to networks having managed devices.
2. Description of the Related Art
The following description is concerned with a data communications system such as a local area network (LAN), that is an Ethernet network. However, the skilled person will appreciate that the present invention will have more general applicability to other types of managed communications systems including wireless networks.
A local area network (LAN) typically comprises a plurality of computers, computer systems, workstations and other electronic devices connected together by a common media such as twisted pair or coaxial cable or fibre optic cable. Data can be communicated between devices on the network by means of data packets (or frames) in accordance with a predefined protocol.
Computers and other devices connected to a network can be managed or unmanaged devices. A managed device has processing capability which enables it to monitor data traffic sent from, received at, and passing through the ports of the device. Monitored data associated with the ports oft he network device is stored in memory on the network device.
Network devices typically represent data in the form of a MIB (Management Information Base), as is well known in the art. A typical managed device may implement a number of MIBs (defined in RFCs), of which one (or more) represents data used in network management, as described below.
An example of a MIB containing network management data is MIB-II (formerly MIB-I) as specified by the IETF (Internet Engineering Task Force). MIB-II is common to core managed network devices of most vendors. Another MIB containing more complex management data is RMON (Remote Monitoring). As is well known in the art, each class or type of management information represented in a MIB is called an xe2x80x9cobjectxe2x80x9d. A specific instance from a data object is called an xe2x80x9cobject instancexe2x80x9d. An object may be defined to have one instance (a scalar object), or multiple instances (a columnar object). Columnar objects are typically organised into xe2x80x9cconceptual tablesxe2x80x9d (hereinafter referred to as xe2x80x9ctablesxe2x80x9d) and all the objects in a table use the same indexing scheme for identifying instances of that object. Thus, tables can be thought of as an array of rows and columns, each column comprising all instances of a particular object and each row comprising the instances of all objects at a common index (the index for the row).
It is becoming increasingly common and necessary for an individual to be appointed to manage a network. The appointed network manager (or administrator) utilises a network management station which includes network management hardware and software. In particular, the network management station is able to access management data from managed network devices using an appropriate management protocol (e.g. the SNMP protocol) and display this data for use by the network manager.
The SNMP (Simple Network Management Protocol) defines the procedure and data packet format for the network management station to access network data from MIBs in managed network devices for TCP/IP-based networks. In SNMP the data packet or PDU (Protocol Data Unit) is defined to have a size of 1500 bytes. The SNMP protocol utilises five main commands: GET, SET, GETNEXT, GETRESPONSE and TRAP.
The GET request is sent by the network management station to a network device to fetch a value of an object or objects from a MIB. The GET request specifies an object using a unique xe2x80x9cobject identifierxe2x80x9d which is defined in the MIB, which includes an index to identify the required instance of the object.
The SET request is sent by the network management station to write a value to a MIB. Like the GET request, the SET request specifies an object identifier of the object whose value should be modified and additionally specifies the new value to be written to the object.
The GETNEXT request, an example of an approximation operation as explained below, is used by the network management station to inter alia fetch object data in MIB tables. The network management station can use the GETNEXT command to fetch the data in a complete MIB table or a part thereof without knowing, in advance, the index values of data stored in the MOB table or part thereof. For example, the network management station will initially send a GETNEXT request specifying the xe2x80x9ctable rootxe2x80x9d. The table root can be thought of as the xe2x80x9ccolumn titlesxe2x80x9d since it is a placeholder after which the first row in the table, that is the row having the lowest index value, is guaranteed to appear. Thus, a GETNEXT request specifying the table root retrieves the first row in the table. The network management station will then use the response to this request in the subsequent GETNEXT command to fetch the next row in the table. The network management station will continue to iterate using the GETNEXT command until the data for all the rows in the relevant MIB table have been fetched.
Thus, because the GETNEXT command is an approximation operation, it does not need to specify the exact index of the object instance to be fetched at each command, as is necessary for the GET and SET commands, but merely an approximation of the index.
If a MIB table is indexed systematically with all indices within a bounded range present, for example 1 to 10, the network management station can issue a direct SNMP GET request for the values in the indexed rows and can pack the maximum number of requests into a single SNMP data packet (1500 bytes for an SNMP PDU) for transmission to the network device. However, if the table index values are sparse, then in the prior art the management station has no choice but to fetch the rows using the GETNEXT command. Because each GETNEXT request uses the response from the previous request, the management station can only fetch one row at a time, since it must wait for the information (i.e. the index value) contained in the response of the previous request before it can formulate the next request (i.e. using the index value as the approximation).
By way of example, a simple MIB table is represented in Table 1 below.
This MIB table, called xe2x80x9ctestTablexe2x80x9d, has two columns, with object identifiers xe2x80x9ctestAxe2x80x9d and xe2x80x9ctestBxe2x80x9d of which xe2x80x9ctestAxe2x80x9d is identified in the MIB as being an index for testTable. Values for testA and testB values are integer values. Thus, the value stored in the xe2x80x9ctestAxe2x80x9d column is the value used to identify (i.e. index) the row in the table. Accordingly, the index which identifies the first row in the table is xe2x80x9c2xe2x80x9d, the index which identifies the second row in the table is xe2x80x9c3xe2x80x9d and the index which identifies the third row in the table is xe2x80x9c7xe2x80x9d. Thus, the rows of testTable are sparsely indexed as 2, 3 and 7 (instead of the systematically indexed 1, 2 and 3).
To fetch the whole of testTable, the network management station will typically send a GETNEXT request for the table root which will retrieve data at the lowest index value, and will then iterate using the previous response as the request each time until all the rows have been fetched. This looks like:
The main problem with the above described known method is that fetching of sparsely indexed MIB tables by the network management station is very slow, which causes delays and generates a lot of data traffic on the network. Furthermore, the utilisation oft he available byte space in data packets is poor.
In network management, it is very common for MIBs to include sparsely indexed MIB tables due to deletions, additions and changes to rows of data which arise during the dynamic operation of a network. Thus, as demands on the network resources increase, the above problems become increasingly significant.
It would be desirable to provide a method and apparatus for fetching sparsely indexed MIB tables in a more efficient manner.
According to a first aspect, the present invention provides a method for fetching sparsely indexed data for at least one data object in a data communications system using a communications protocol which defines a data packet format and an approximation operation, whereby the approximation operation retrieves the data object which has the closest available index value to, and which is greater than or less than, an approximation of the index value specified in the approximation operation, the method comprising sending a plurality of approximation operations in a first data packet, at least one of the plurality of approximation operations specifying a speculative approximation.
By employing speculative approximations of index values of data objects to be fetched, a network management station operating in accordance with the method of the present invention can include a plurality of approximation operations in a data packet, thus improving the speed of retrieving a table of data and utilising more of the byte-space available in a data packet in comparison with the known method.